Distributed hypermedia method and system for automatically invoking external applications providing interaction and display of embedded objects via a scripting platform

ABSTRACT

A system is described which provides the capability for high-level extensible scripting language interpreters to incorporate and employ Web browser plug-ins as components within script-based programs. A script interpreter extension is described which simulates the plug-in API interface of a Web browser, from the point of view of the browser plug-in, to allow program scripts to cause browser plug-ins to be launched and manipulated, in a manner similar to the scripting platform&#39;s native widgets, from within the executing program script. This system allows embedded external program objects to be used to display and enable interactive processing of embedded data objects.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of and claims the benefit of U.S.patent application Ser. No. 11/058,436 filed Feb. 14, 2005, thedisclosure of which is incorporated herein by reference.

BACKGROUND OF THE INVENTION The Interactive Content Paradigm

Computer application paradigms go through a constant process ofevolution. Fifteen years ago, personal productivity applicationstypically were text-based, ran in full screen mode, and each applicationtended to employ a unique set of user interaction commands. Asmulti-windowed graphical user interface systems became popular,applications developed for these environments began to adopt standardtypes of interface models, to minimize users' confusion as they switchedback and forth among multiple open applications. As a result of featurecompetition among vendors, productivity applications built for thesewindowed environments began to grow larger and larger. Simultaneously,users began to demand easy transfer of data between documents createdwith various applications. This led to the creation of compound-documentarchitectures, such as Microsoft's Object Linking and Embedding (OLE)system. OLE-based applications were designed from a document-centricmindset, allowing several large monolithic productivity applications toshare a single document view and “trade off” the graphical interface, sothat the user wouldn't have to move his or her eyes away from thedocument being worked upon as each application was interactivelyactivated (usually with a double click on a bitmap in the document) bythe user. This model worked well enough when only a few majorapplications were involved, and when the user was primarily interestedin editing documents which would be printed for use. The growth of theWeb, however, ushered in a new use for document files—as a direct toolfor networked communications and information retrieval.

The Web's new plug-in and applet technology created a new paradigm forapplication development. This new system focused on the document as acontainer for multiple small embedded program objects, rather than asthe OLE-style task switcher of the Windows model. This new system alsoushered in a new interaction paradigm, as well. The Web document becamethe primary application, with the document automatically choreographingthe collection of document component data and the activation of theembedded applications necessary to present the user with a single andseamless interactive interface to the document's content.

The UCSF/Eolas WAPI

The Web-document-as-application model was first established at theUniversity of California, San Francisco's Center for KnowledgeManagement. Their work, and their proposal for a standard Web API(WAPI), was described in the lead article of the February, 1996, issueof Dr. Dobb's Journal. This technology allowed the creation and use of“plug-in” applications that Web content authors could easily employ todynamically extend the functionality of WAPI-enhanced Web browsers andWeb pages at viewing time, without having to modify the actual browsercode. Although WAPI did not, itself, become an industry standard, itinspired later commercial systems that went on to transform the entirecomputer software industry.

The Netscape Plug-In API

Essentially modeled upon the UCSF/Eolas WAPI, the Netscape browserplug-in API created a de facto standard that has been implemented in allmajor browsers. This resulted in the subsequent development of hundredsof plug-ins that were then made freely available online, all of whichconform to a standard architecture. The availability of such a largenumber of application components has made the very popular and powerfulplatform for application development. The Web document parsing modelallows late binding of these application components, together withruntime fetching of component-specific data objects, thereby insuringthat users can both always enjoy the latest improvements to componentprograms and always see the latest updates to embedded object data. Italso allows application design to be independent of underlying computersystem architecture. This has proven to be a very effective means forapplication integration with legacy software systems, proving verypopular among corporate applications developers.

Scripting Languages

Modern scripting languages, such as Tcl/Tk, provide the ability to writetext scripts which define interactive applications through run-timeparsing of script files. Similar to the situation with Web pages, thistype of architecture provides for late binding of applicationfunctionality through such runtime script parsing. Tcl/Tk provides astandard APIs for enhancing both the command set and widget set of theinterpreter through interpreter extension that are loaded at runtime.Although this provides some advantages similar to those of browserplug-ins, there are not nearly as many widget extensions available asthere are browser plug-ins. Furthermore, the interpreter extensionmechanism did not make provision for late binding of componentapplication code with application data, as the browser plug-in modeldoes.

What is Needed

A system is needed that allows general program development systems tobenefit from the large number of embeddable applications, in the form ofbrowser plug-ins, that are available to easily expand the functionalityof these development platforms at run-time, as well as to provideruntime binding of component logic with remotely-networked data objects.

SUMMARY OF THE INVENTION

The present invention provides these useful advantages through the noveland counterintuitive synthesis of existing industry-standard Web browsertechnology with script language interpreter extension technology.Although widgets are developed specifically for use as extensions to aparticular scripting language the base to support development of suchapplications is small compared with the base to support development ofplug-in applications. Thus, the present invention allows script basedapplications to tap into the vast pool of functional resources providedby web-browser plug-in applications.

According to one aspect of the invention, plug-in extension codeincludes code for parsing a program script to detect an embed command,for fetching an object referenced by the embed command, and simulating aweb-browser interface to automatically invoke a web-browser plug-inidentified by the data format of the object.

According to another aspect of the invention, the plug-in interfaceallows web-browser plug-ins to be used by the script-based applicationas embedded widgets.

According to another aspect of the invention, the plug-in interfaceallows the plug-in application to interactively display and manipulatethe object in a child window controlled by the script-based application.

According to another aspect of the invention, the object if fetchedusing standard internet protocols such as http or file access.

According to another aspect of the invention, the interpreter extensionmechanism provides for late binding of code and application data.

Other features and advantages of the invention will be apparent in viewof the following detailed description and appended drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a layer diagram of a preferred embodiment of the invention;and

FIG. 2 is a block diagram of a standard computer system.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

A preferred embodiment will now be described that utilizes the ToolCommand Language and Tool Kit (Tcl/Tk) which is scripting languageuseful for WWW-based applications. Tcl/Tk was developed by JohnOusterhout and is described in his book entitled, Tcl and the TkToolkit, Addison-Wesley, ISBN 0-201-63337-X, 1994. However, theinvention is generally applicable to any scripting language such as, forexample, Perl, Python, Rexx, or Visual Basic.

In a preferred embodiment, an extension to a scripting languagesimulates a browser from the point of view of a plug-in, in order forthe plug-in to be embeddable within a script program interface, andmanipulable in a manner similar to a native widget. Program code in theextension provides the same functions and interfaces to a plug-in asprovided by an industry-standard Web browser application programminginterface (API). From the plug-in's viewpoint, the extension appears tobe a conventional Web browser. Data objects are referenced in “SRC”parameters in the scripting language command syntax. These data filesare fetched at run time using standard Web protocol conventions (e.g.:http or file access). The script text file is parsed by the scriptinterpreter at run time to identify language commands. A new scriptcommand is created which mimics a standard hypermedia embed text format.This command then causes the plug-in-interface extension to invoke codein the extension that allows the browser plug-in to be automaticallyinvoked in order to allow display and interaction with embedded objects,whereby those embedded objects are treated by the scripting languageplatform as interactive widgets which can be embedded within the scriptprogram graphical user interface.

One embodiment of the invention employs a “wrapper” utility, written inthe script language, which defines a procedure which is able to parseand respond to an embed text format (an EMBED tag) which may be copiedfrom a conventional HTML page and pasted into a program script. Thewrapper utility procedure does this by parsing the EMBED tag, fetchingthe file defined by the “src=” attribute of the tag, and invoking theplug-in extension, while passing any associated EMBED tag parameters tothe plug-in as passed arguments via the script language's argumentpassing mechanism.

FIG. 1 is a layer diagram of a preferred embodiment of the invention.The upper block 10 of FIG. 1 represents a standard scripting languageconfiguration including a user-interaction interface, script-basedprogram, script interpreter, and extension API.

Sub-blocks 12 and 14 represent different script interpreter plug-inextensions sub-blocks. Each sub-block includes a plug-in extension whichsimulates a web-browser interface to the browser plug-in application andalso allows the plug-in application to interactively control andmanipulate the fetched object in window controlled by the script-basedprogram.

The following is a list of API functions simulated by the plug-extensionin a preferred embodiment to simulate the plug-in interface of aNetscape web-browser:

Example Netscape browser plug-in API functions to be simulated:

#ifdefXP_UNIX    NPError NPN_GetValue(NPP instance, NPNVariablevariable,    void *value); #endif/* XP_UNIX */   voidNPN_Version(int*plugin_major, int*plugin_minor, int*netscape_major, int*netscape_minor);   NPError NPN_GetURLNotify(NPP instance, conist char*url, const char* target, void* notifyData);   NPError NPN_GetURL(NPPinstance, const char* url, const char*   target);   NPErrorNPN_PostURLNoIify(NPP instance, const char* url, const char* target,uint32 len, const char* buf, NPBool file, void* notifyData);   NPErrorNPN_PostURL(NPP instance, const char* url,    const char* target, uint32len, const char* buf; NPBool file);   NPError NPN_RequestRead(NPStream*stream, NPByteRange*   rangeList);   NPError NPN_NewStream(NPP Instance,NPMIMEType type,    const char* target, NPStream** stream);   int32NPN_Write(NPP instance, NPStream* stream, int32 len,    void* buffer);  NpError NPN_DestroyStream(NPP instance, NPStream* stream,    NPReasonreason);   void NPN_Status(NPP instance, const char* message);   constchar* NPN_UserAgent(NPP instance);   vold* NPN_MemAlloc(uint32 size);  void NPN_MemFree(void* ptr);   uint32 NPN_MemFlush(uint32 size);  void NPN_ReloadPlugins(NPBool reloadPages);  JRIEnv*NPN_Get_JavaEnv(void);   jref NPN_GetJavaPeer(NPP instance);

Function name Description NPN_GetValue Get a value NPN_Vetsion Returnthe major & minor version Numbers for the Plugin protocolNPN_GetURLNotify Get a Stream URL and return the result via a call toNPP_URLNotify NPN_GetURL Get data from a URL. NPN_PostURLNotify Postdata to a server. NPN_PostURL Post data to a server. NPN_RequestReadRequest a range of bytes from a seekable stream to be sent to the pluginin subsequent NPP_Write calls, An fseek equivalent. NPN_NewStreamCreates a new stream for data flow from plug-in to browser. NPN_WriteCalled from the plugin to write data to a stream created withNPN_NewStream. NPN_DestroyStream Destroy the stream created with theNewStream call. NPN_Status A line of text sent by the plugin to thebrowser, ostensibly to display on the ‘status’ line. NPN_UserAgentRetrieves the User-Agent field from the Navigator. Just ship back apro-defined string? NPN_MemAlloc Allocates memory, map to TclAlloc.NPN_MemFree Frees memory, map to TclFree. NPN_MemFlush Frees memory inthe browser to make more room for plugin. NPN_GetJavaEnv Returns theJava execution environment. NW_GetJavaPeer Returns the plug-inassociated with a Java object.

Summary of basic system elements for a Tcl/Tk implementation.

-   -   A new set of Tcl commands that load and operate plug-ins. Code        in the plug-in-interface extension (a Tcl/Tk loadable extension,        see Practical Programming in Tcl/Tk, by Brent B. Welch, 2nd        Edition, pub: (1997) Prentice Hall; ISBN: 0136168302 reference        for Tcl/Tk extension API) provide the same functions and        interfaces to a plug-in as provided by an industry-standard Web        browser    -   Parsing code in the plug-in-interface extension allows the        standard <EMBED . . . > tag parameters to be passed as part of        the Tcl command call    -   Code in the plug-in-interface extension allows data objects        referenced in “SRC” parameters to be fetched using standard        conventions (e.g.: http or file access)    -   Code in the plug-in-interface extension allows script to be        parsed to identify embed text formats and to automatically        invoke the browser plug-in application    -   Code in the plug-in-interface extension allows the plug-in        application to be automatically invoked to allow display and        interaction with embedded objects, whereby those embedded        objects and their associated plug-in applications are treated by        the scripting language platform as widgets.    -   Code in the plug-in-interface extension allows the plug-in        application to display and provide interactive processing of a        data and/or program object within a child window, said window        which is embedded within a Tcl/Tk-controlled window, under        control of the program script.

The details of the implementation of a preferred embodiment are setforth in the source code appendix to this patent application.

FIG. 2 is an illustration of basic subsystems of a computer systemsuitable for use with the present invention. In FIG. 2, subsystems arerepresented by blocks such as central processor 180, system memory 181consisting of random access memory (RAM) and/or read-only memory (ROM),display adapter 182, monitor 183 (equivalent to display device 153 ofFIG. 3), etc. The subsystems are interconnected via a system bus 184.Additional subsystems such as a printer, keyboard, fixed disk and othersare shown. Peripherals and input/output (I/O) devices can be connectedto the computer system by, for example serial port 185. For example,serial port 185 can be used to connect the computer system to a modemfor connection to a network or serial port 185 can be used to interfacewith a mouse input device. The interconnection via system bus 184 allowscentral processor 180 to communicate with each subsystem and to controlthe execution of instructions from system memory 181 or fixed disk 186,and the exchange of information between subsystems. Other arrangementsof subsystems and interconnections are possible.

The invention has now been described with reference to the preferredembodiments. Alternatives and substitutions will now be apparent topersons of skill in the art. In particular, the invention is applicableto all extensible scripting languages and is not limited to anyparticular set of existing scripting languages. The differences betweenscripting languages and system languages and the fundamentalcharacteristics of scripting languages are set forth in an article byJohn Ousterhout entitled, Scripting: Higher Level Programming for the21st Century, IEEE Computer Magazine, March, 1998.

Further, although the preferred embodiment simulates the plug-ininterface of a Netscape browser application, the nature of extensiblescripting language allows the principles of the invention to be extendedto any browser application.

Accordingly, it is not intended to limit the invention except asprovided by the appended claims.

1. A method for running an application program in a distributedhypermedia network environment, wherein the network environmentcomprises at least one client workstation and one network server coupledto the network environment, the method comprising: receiving, at theclient workstation from the network server over the network environment,at least one file containing information to enable a scripting platform,which does not allow navigation among web pages, to display at least aportion of an object external to the file within a window controlled bysaid scripting platform; executing the scripting platform on the clientworkstation, with the scripting platform: responding to text formats toinitiate processing specified by the text formats; displaying at least aportion of the object within the window controlled by said scriptingplatform; identifying an embed text format in said file, where the embedtext format specifies the location of at least a portion of said object,where the object has type information associated with it; utilizing thetype information to identify and locate an executable applicationexternal to the file; and automatically invoking the executableapplication, in response to the identifying of the embed text format, toexecute on the client workstation in order to display the object andenable an end-user to directly interact with the object while the objectis being displayed within a display area created within the windowcontrolled by said scripting platform.